fix(ci,#15091): copies de reference ai-01 — drop-in tracké, et le dépôt n'écrase plus la borne mémoire vivante - #15214

Grain: MED/guard — lane myia-ai-01:CoursIA — prev: MED/guard #15211

(Genre requalifié une seconde fois, docs → guard, aux commits c08713c4e…c9f3cfcd5 : la branche porte désormais 1371 lignes de contrôle exécutable — un dry-run qui échoue et un harnais de tests qui rougit — contre 287 de README. Le discriminant guard vs tooling du protocole de variation est « est-ce que ça peut rougir » : oui des deux côtés. Classe MÉTA inchangée, donc G-VAR-1 reste non tenu par cette PR — une CONTENU est due à ma lane.)

(Requalification précédente, tooling → docs au commit 4e28e98bd : le livrable dominant est désormais la correction de persist/README.md et la synchronisation d'une copie de référence, pas un outil.)

Le drop-in qui borne la mémoire du pool ai-01 vivait sur la machine et nulle part ailleurs. Cette PR le met sous git — et corrige ce que les versions précédentes de ce travail affirmaient à tort, y compris une consigne de déploiement qui aurait retiré la borne mémoire de la machine.

⚠️ Ce que cette PR corrige d'elle-même (commit 4e28e98bd)

Le bloc de déploiement de persist/README.md aurait cassé la protection qu'il documente. Son étape 1 disait, sans condition :

install -m 0644 persist/coursia-ci.slice /etc/systemd/system/coursia-ci.slice

Mesure firsthand du 2026-09-08 sur ai-01 (wsl.exe -d Ubuntu -u root --) :

Exécuter cette étape aurait donc retiré les trois bornes mémoire de la machine — la protection exacte que le mandat user demandait de poser. Le fichier vivant était en avance sur le dépôt, pas l'inverse.

Deux autres cellules de la table d'état étaient fausses au même endroit :

Ce qui est fait :

• persist/coursia-ci.slice synchronisé depuis le vivant — le dépôt en était un sous-ensemble strict, git diff --numstat rend 56 0 (56 lignes ajoutées, 0 retirée). La seule ligne encore différente est un commentaire, neutralisé côté dépôt parce qu'il nommait une personne privée ; le fait technique — quatre redémarrages manuels sur site dans la journée — est conservé.
• Étape 1 du déploiement : install inconditionnel → diff préalable, les deux install laissés en commentaire.
• Le paragraphe « 0 conteneur » corrigé, et il dit ce qui n'a pas été vérifié : "live-restore": true est déclaré dans daemon.json, sa tenue au restart n'a pas été testée ici.
• Nouvelle correction 6 ; la section passe de « cinq » à « six corrections ».

La leçon écrite dans le fichier : « le dépôt est la référence » est une convention, pas une mesure. La dérive va dans les deux sens, et c'est le fichier vivant qui tient la machine debout pendant que la copie dort. Avant tout install vers un chemin vivant : diff d'abord, et lire le diff.

🔻 Rétractation — « 16 vCPU servis en silence » était trop fort

Le README écrivait « les 16 vCPU étaient demandés et servis en silence », et le drop-in de référence « 16 tournaient donc ». Les deux surévaluent la gravité, et je les retire.

Déclaration n'est pas consommation, et il y a deux bornes, pas une. assert_cpu_budget() est un refus au démarrage ; le plafond kernel, lui, est coursia-ci.slice — CPUQuota=800%, soit cpu.max 800000 100000 — et il était armé et actif tout du long (mesuré : la slice existe, ses contrôleurs sont posés, le pid d'un waiter s'y trouve). La machine porte par ailleurs nproc = 32 : 8 est le budget consenti à la CI, pas la taille du processeur.

Autrement dit : la famille aurait demandé 16 vCPU, et le noyau lui en aurait servi 8, avec throttling. Retirer le garde a supprimé le refus lisible, pas le plafond. La sur-souscription reste un vrai défaut — elle étrangle en silence au lieu de refuser franchement — mais elle n'a jamais laissé la CI consommer 16 vCPU.

La table « Les trois bornes » du README disait déjà la bonne chose de COURSIA_RUNNER_CPU_BUDGET (« c'est un refus de démarrage, pas un plafond kernel ») : la prose contredisait son propre tableau.

Le défaut d'origine, mesuré

persist/ai-01/coursia-runner.service (tracké) déclare ExecStart=… 8 et aucun COURSIA_RUNNER_MEMORY. supervise.sh l.82 lit alors son défaut :

MEMORY="${COURSIA_RUNNER_MEMORY:-4g}"

Le garde de budget refuse et le pool ne monte jamais. Le récit que j'en faisais — « Restart=always reboucle toutes les 30 s » — était faux sur la durée : StartLimitBurst arrête la boucle. Mesure du 2026-09-08 sur la machine : refus à 16:23:40, puis Start request repeated too quickly à 16:24:11, et plus rien après. systemd a renoncé en 31 secondes.

Cette borne change le diagnostic dans le mauvais sens : coursia-runner n'est pas un service qui bat, c'est un service silencieusement absent. Une boucle laisse une trace qui se voit ; une renonciation ne se signale plus. Et le refus étant déterministe — il ne dépend d'aucune course, d'aucune charge — il rejoue à l'identique à chaque démarrage : redémarrer la machine ne peut pas le lever. C'est la panne qui a imposé quatre redémarrages manuels de la machine dans la même journée, chacun par une intervention sur site — quatre fois le même geste contre une cause que ce geste ne touche pas.

Pourquoi ce n'était pas déjà fermé

persist/README.md marque la copie 8-slots « à déployer ». Le fichier qui la rend sûre — le drop-in — était untracked. Un déploiement fidèle à la consigne du README reproduisait donc la panne à l'identique. La porte n'était pas seulement ouverte : elle était fléchée.

Le drop-in ne suffit pas — et l'écrire autrement serait faux

La version initiale de cette PR affirmait que ce fichier « tient la machine debout » et que le dimensionnement en place « est sain ». C'est mesurablement faux, sur un axe que la mesure initiale ne regardait pas. Le drop-in borne la mémoire et ne pose rien sur le CPU :

Mesure du 2026-09-08 à 14:49Z, la même journée :

$ systemctl show coursia-runner -p ActiveState -p NRestarts -p Result
ActiveState=failed
NRestarts=4
Result=exit-code

journal : ERREUR: budget CPU inter-familles depasse : 16.00 vCPU demandes pour un plafond de 8.
            deja actif : waiters n=4 cpus=1 -> 4.00
            demande    : start n=4 cpus=3 -> 12.00

L'histoire du défaut — hypothèse retirée, mesure à la place

J'avais avancé que l'écart entre un matin sain et un après-midi en échec venait de l'ordre de démarrage des familles. Cette causalité n'était pas établie et je la retire. Elle est réfutée deux fois :

1. Par arithmétique — la famille start demande 4 × 3 = 12 vCPU à elle seule contre un plafond de 8. Elle échoue même en partant la première, waiters éteints. Aucun ordre ne la fait passer.
2. Par le journal — les trois démarrages réussis du matin (08:33:52, 08:34:43, 09:29:41 CEST) logguent 4 slot(s) ; cpus=3 alors que les waiters étaient déjà à n=4 (08:33:52). Les 16 vCPU étaient donc déclarés le matin aussi, et acceptés sans un mot — déclarés, pas consommés : cf. la rétractation ci-dessus.

Ce qui a changé est le garde, pas l'ordre. assert_cpu_budget() sort immédiatement quand le budget vaut 0 (l.422) et n'imprime alors rien ; sa ligne de succès (l.444) est absente de tout le journal disponible depuis le 2026-09-02. Le wrapper portant COURSIA_RUNNER_CPU_BUDGET:-8 a été écrit sur la machine à 09:47:21 CEST — après le dernier succès, avant la première ERREUR (16:11:53).

Les deux moitiés du défaut sont dans mon propre travail : le drop-in pose la sur-souscription, et #15103 (93c05cf10, seul commit introduisant COURSIA_RUNNER_CPU_BUDGET) arme le déclencheur au-dessus — aucune des deux n'a confronté les deux chiffres.

Le contrôle de dimensionnement — un dry-run qui échoue plutôt que d'approuver

Le dimensionnement CPU était alors ouvert, et c'est ce qui a
motivé la suite : quatre commits (c08713c4e…c9f3cfcd5) ajoutent le contrôle
non mutant qui permettra de le trancher sans toucher à la machine.

persist/ai-01/dryrun-sizing-control.sh — il n'écrit rien dans /etc ni dans
/usr/local/bin, n'appelle systemctl qu'avec show / cat / is-active, ne
redémarre ni docker ni WSL, et ne touche aucun quota de slice. Onze sections :
configuration effective (tous drop-ins fusionnés), budget lu à la source qui
fait foi, l'écart fichier ≠ processus qui est la mèche latente, plafond noyau,
arithmétique du garde, capture d'un bundle des octets vivants, drop-in
proposé dans le bundle et pas dans /etc, rollback borné à la cible,
auto-vérification, commandes d'application à relire, témoins à relever.

La propriété centrale a été ajoutée après coup, parce que la première version
avait le mauvais mode de défaillance. Elle rendait « passe » quand le budget
était illisible : budget non lu → 0, et total > budget est faux quand
budget vaut 0. Un dry-run dont le mode de défaillance est approuver est pire
que pas de dry-run. Toute source requise absente, illisible ou non interprétable
est désormais fatale, et l'absence de garde se dit au lieu de se confondre
avec un succès.

Les quatre points de la review de coursia-1d, et ce qu'ils ont changé

Le principe est le même aux quatre : quand l'instrument ne sait pas étayer un
verdict, refuser vaut mieux qu'un verdict approximatif — qui a l'air d'avoir
marché. Le premier point est le plus traître : systemctl show -p Environment ne
rend que les Environment= inline, et le contenu d'un EnvironmentFile= est
lu par systemd à l'exécution. Une valeur posée là serait lue ABSENTE, avec
repli sur le défaut du wrapper : l'erreur irait dans le sens permissif.

Le défaut que le quatrième point a fait sortir — et que la review n'avait pas nommé

Grepper le texte du script généré prouve qu'il contient des mots, jamais
qu'il restaure. En l'exécutant, un défaut latent est apparu : TARGET_ABS
servait à la fois de clef de bundle et de destination. Sous une racine de
test, le rollback généré visait donc le vrai /etc. Un rollback qui restaure
ailleurs que là où il a mesuré est pire qu'absent. TARGET_DEST (destination
réelle, telle qu'inspectée) est désormais distinct de TARGET_ABS (chemin
canonique, clef du bundle) — en production ROOT est vide, les deux coïncident,
comportement inchangé octet pour octet.

Une assertion pinglait le défaut qu'elle aurait dû attraper. La section F
grepait rm -f "/etc/systemd/...", c'est-à-dire le chemin ROOT-strippé :
corriger le bug la faisait échouer. Elle accepte maintenant la racine inspectée,
et la vérification forte vit en J1/J2, qui exécutent et constatent l'effet
dans la fixture.

Le harnais

persist/ai-01/test-dryrun-sizing-control.sh, 11 sections A–K. Faux
systemctl, faux chown et faux ls uniquement ; aucun service réel touché,
aucun redémarrage, aucun chemin /etc réel écrit. La section I porte 7 tests
de bornage dont 2 contrôles négatifs (drop-in lu avant la cible, cible
nominale) — sans eux, sept refus prouveraient seulement que le script refuse tout.

Mesures fraîches à la tête b153717a8, code de sortie capturé immédiatement
— un rc=$? posé après un echo intervenant mesure l'echo, et mon propre
lanceur avait ce défaut : il rendait rc=0 pour une suite qui sortait 1.

Les deux plateformes ne rendent pas le même compte, et c'est voulu : ce qui
n'est pas exerçable ici est déclaré, jamais compté comme un succès.

Le défaut trouvé en exerçant la suite sous WSL — un aveu qui s'effaçait

Le skip K6 (refus sur ACL étendues) vivait dans le else du test de capacité
K5 (symlinks). Sur une plateforme capable de liens réels, la non-couverture ACL
ne se dégradait donc pas : elle disparaissait.

La ligne finale « ils restent NON couverts, ce n'est pas un succès » ne pouvait
alors plus les nommer, faute de compteur. Un aveu qui s'efface est pire qu'un
aveu bruyant. Correctif (b153717a8) : deux capacités, deux conditions, deux
déclarations.

• K5a cible = lien symbolique → refus (exercé sous WSL)
• K5b répertoire .d = lien symbolique → refus — ici [ -L cible ] est
  faux, c'est le second garde qui doit mordre ; sans ce cas, un seul des
  deux refus serait exercé
• K6a ACL étendue réelle posée par setfacl → refus, sinon skip
  déclaré — c'est le cas qui reste non couvert ici
• K6b faux ls émettant un + → refus
• K6c contrôle négatif : le même faux ls sans + → ne refuse rien

K6c n'est pas décoratif : un script qui refuserait toujours passerait K6b
sans rien prouver — même famille de défaut que le marqueur printf plus haut.
Et la capacité ACL se mesure par son effet (le + apparaît-il dans
ls -ld ?), jamais par la présence de setfacl : un setfacl présent mais
inopérant sur le système de fichiers du scratch rendrait un test vert qui
n'exerce rien.

Validé par ses faux négatifs — chaque défaut réinjecté un par un dans le
script de contrôle, en scratch jetable, avec garde d'ancre (un sed sans
effet est rapporté « ANCRE MANQUÉE », jamais lu comme un succès) :

dryrun-sizing-control.sh est inchangé par ce commit — son empreinte est la
même avant et après (sha256:d7d39e8ca0a2…), ce qui est la propriété attendue
d'un correctif qui ne touche que le harnais.

Ce qui reste non couvert, et le reste explicitement : le refus sur une ACL
étendue réelle (K6a), faute du paquet acl sur le WSL Ubuntu d'ai-01.
L'installer est une opération sudo apt sur le serveur de flotte — elle n'a
pas été faite unilatéralement, et elle est proposée séparément.

Le faux chown mérite d'être dit franchement : sur Git Bash stat -c '%U:%G' rend
MYIA:UNKNOWN, que chown refuse — mesure faite, pas supposée. Le faux
enregistre la demande. Ce que cela prouve : le rollback demande la
restitution du propriétaire exactement tel que stat l'a relevé. Ce que cela ne
prouve pas : que chown réussisse ici — sur la cible Linux il est réel, et c'est
la seule machine où ce rollback a vocation à tourner.

Ce que la PR change

• NOUVEAU persist/ai-01/coursia-runner.service.d/10-sizing.conf — copie de référence du drop-in vivant, avec un en-tête de provenance qui dit ce qu'il ne fait pas.
• persist/coursia-ci.slice — synchronisé depuis le fichier vivant (+56 / −0), dépersonnalisé dans le même geste.
• persist/ai-01/coursia-runner.service — commentaire seul, aucune directive touchée.
• persist/README.md — table d'état corrigée sur trois cellules, bloc de déploiement gardé par un diff, corrections 4, 5 et 6.
• NOUVEAU persist/ai-01/dryrun-sizing-control.sh — 697 lignes, 35352 octets, sha256:d7d39e8ca0a23af1… — le contrôle non mutant décrit ci-dessus.
• NOUVEAU persist/ai-01/test-dryrun-sizing-control.sh — 674 lignes, 31601 octets, sha256:656a57ac430328b2… — son harnais : 76 / 0 / 1 sous WSL, 74 / 0 / 2 sous Git Bash.

La strophe opérante du drop-in tracké est byte-identique au fichier vivant. Mesure refaite en lecture seule à la tête b153717a8. La règle d'extraction est écrite ici, sans quoi le chiffre ne se rejoue pas : lignes non commentées, lignes vides retirées.

L'écart de volume est l'en-tête de provenance de la copie trackée, qui dit ce que le fichier ne fait pas ; il ne porte aucune directive. Aucun fichier exécuté par un service vivant n'est modifié ; supervise.sh n'est pas touché, seulement cité en lecture.

La formulation antérieure — « aucun fichier exécuté n'est touché » — est devenue fausse aux commits c08713c4e…c9f3cfcd5, qui ajoutent deux scripts exécutables ; coursia-1d l'a relevée à la relecture, et la phrase est corrigée plutôt que défendue. Ce qui reste vrai est plus étroit et se vérifie : ces deux scripts sont neufs, ne remplacent aucun fichier et ne sont référencés par aucune unité systemd.

Une seconde formulation est devenue fausse, et je la corrige aussi : « ils n'ont jamais tourné sur la machine ». dryrun-sizing-control.sh a été exécuté sur ai-01, le 2026-09-08 à 17:40:18Z, soit 19:40:18 CEST — c'est précisément son objet, et il est non mutant par construction. Son bundle a été capturé six minutes plus tard, à 17:46:03Z / 19:46:03 CEST (en-tête de state-before.txt) : la rédaction antérieure accolait l'heure UTC du run à l'heure locale de la capture, deux instants distincts donnés à lire comme un seul — relevé par coursia-1d. Ce qu'il a produit est un bundle en /tmp, pas une écriture dans /etc : /tmp/dryrun-live-2/ avec state-before.txt, proposed/10-sizing.conf, rollback.sh et manifest.tsv. Le harnais de tests, lui, s'exécute entièrement en fixture, sur systemctl, chown et ls factices. Aucun /etc écrit, aucune unité redémarrée, aucun déploiement effectué.

Arbitrage de dimensionnement — tranché par coursia-1d

Le dimensionnement du contrôle initial n'est plus indéterminé. Il n'a
pas été tranché par cette lane : coursia-1d l'a arrêté, et c'est
cet arbitrage qui fait foi.

Rétractation — « un seul facteur bouge » était faux

La version précédente de ce body écrivait « COURSIA_RUNNER_MEMORY=1536m
inchangé — un seul facteur bouge », et écartait la variante quatre slots à
1 vCPU au motif qu'elle « change deux facteurs à la fois ». coursia-1d
a relevé que cet argument se retourne contre la configuration retenue, et il a
raison : je retire les deux phrases.

Passer de 4 × 3 à 1 × 2 bouge les deux mêmes facteurs :

Le seul invariant est le plafond mémoire par conteneur. Écrire « un seul
facteur bouge » masquait que la famille start change de dimension sur ses deux
axes à la fois — et rendait l'argument d'attribution inutilisable, puisque la
variante rejetée n'était pas pire que la retenue sur ce point précis.

Ce que ce contrôle initial peut donc réellement témoigner : le démarrage
et l'acquisition d'un job par un slot unique. Rien d'autre. Il ne dit rien du
parallélisme, du débit, ni du comportement de la famille à plusieurs slots — un
slot ne peut pas témoigner de ce qui n'existe qu'à plusieurs. Toute lecture de ce
témoin au-delà de « un slot démarre et prend un job » serait une extrapolation.

Et le critère de réussite exige les DEUX témoins, pas un seul. La ligne de
garde budget CPU inter-familles : N / M vCPU — jamais émise sur cette machine
à ce jour, ce qui fait de sa première apparition un fait observable — atteste que
le budget a été calculé puis franchi : elle témoigne du démarrage, et de rien
de plus. L'acquisition effective d'un job par le slot est un fait distinct,
qui demande son propre relevé dans le journal du runner. Un contrôle qui
s'arrêterait à la ligne de budget déclarerait réussi un slot démarré qui ne
prend aucun job — exactement la moitié du témoin annoncé juste au-dessus.
coursia-1d a relevé cette insuffisance ; le critère est donc conjonctif.

Ce qui n'est PAS retenu : quatre slots à 1 vCPU — la variante que j'avais
avancée, au motif qu'elle sature exactement le budget (8/8, que le prédicat >
strict laisse passer). Il en reste deux raisons, celles qui tiennent :

1. elle ne laisse aucune marge sous le plafond ;
2. cpus=1 étrangle : un job réel a été vu à 129 % CPU.

Le protocole #15095 « un slot avant plusieurs » s'applique : on fait passer
un slot, on le regarde terminer un vrai job, et toute montée en capacité
demande ensuite des mesures fraîches — pas une extrapolation.

Ce dernier point n'est pas une précaution de principe : ma précédente
extrapolation de sizing s'est déjà trompée une fois, et le cap
1536 Mo qui en était issu a fait OOM un rendu Quarto.

Cette PR ne l'applique pas. L'arbitrage est consigné ici pour qu'il
survive à la session qui l'a rendu ; l'application reste un geste séparé,
qui dépend de la contre-vérification en cours et n'a reçu aucune
autorisation à ce jour.

Portée — ce que cette PR ne fait PAS

Elle ne corrige pas la panne, elle la documente et empêche un déploiement destructeur. Le dimensionnement CPU n'est plus indéterminé — la section précédente porte l'arbitrage — mais cette PR ne l'applique pas : elle n'écrit rien dans /etc, ne redémarre aucune unité, et le drop-in tracké reste byte-identique au fichier vivant. La mesure qui borne le choix tient toujours : un job réel a été vu à 129 % CPU, donc cpus=1 l'étranglerait — c'est précisément pourquoi le slot initial en reçoit 2. Ce qui demeure ouvert est la capacité au-delà du contrôle initial : elle dépend d'un vrai job terminé et de mesures fraîches.

Elle ne déploie rien : la synchronisation va du vivant vers le dépôt, jamais l'inverse.

Historique de cette branche

Les deux premiers commits ont été réécrits (--force-with-lease, branche à lane unique) pour retirer de l'historique public des détails personnels sur un proche du user, qui figuraient dans l'en-tête du drop-in, le README et ce body. Ils n'apportaient rien au diagnostic. Le fait technique — quatre redémarrages manuels sur site — est conservé partout.

Préflight

• check_lane_claim.py 15091 --lane myia-ai-01:CoursIA --paths 'persist/ai-01/**' → CLEAR, 0 bloqué / 3 libres.
• --open-prs-on 'persist/ai-01/**' → aucune PR ouverte n'intersecte. (fix(ci,#15095): borner le superviseur runners quand Docker est indisponible #15166 et fix(ci,#15091): sparse-checkout cone sur pr-gate.yml + bornes restart/IO sur les unites du parc #15094 touchent persist/coursia-runner.service, la copie po-2024 à plat — fichier différent.)
• gitleaks v8.24.3 (version épinglée, .pre-commit-config.yaml et secret-scan.yml concordent) — 0 finding sur persist/ et sur origin/main..HEAD. Contrôle positif passé : un jeton GitHub synthétique déposé dans un fichier jetable est bien détecté (rc=1), donc le zéro ci-dessus est une mesure, pas un instrument muet.
• Contrôle de confidentialité re-passé sur le diff complet à la tête b153717a8 : 1815 lignes +, 0 hit. Détecteur validé d'abord sur son propre témoin (contrôle positif vu, contrôle négatif muet) — sans quoi son silence ne mesurerait rien.
• bash -n OK sur les deux scripts. Suite exécutée après le dernier commit, sur les deux plateformes : 76 / 0 / 1 sous WSL Ubuntu, 74 / 0 / 2 sous Git Bash, rc=0 des deux côtés.
• Le plancher de dwell de 2 h est ré-armé par le commit b153717a8 (poussé le 2026-09-08). Le merge appartient à coursia-1d ; cette PR ne peut pas être mergée avant l'échéance, et ce n'est pas un défaut à réparer.
• Rien n'a été appliqué, déployé ni redémarré. Toutes les commandes de cette tranche étaient en lecture seule ou confinées au worktree et au scratchpad. Le Ne rien appliquer de coursia-1d tient.

See #15091